1. Field of the Invention
The present invention relates generally to computer systems equipped with a universal serial bus (or xe2x80x9cUSBxe2x80x9d) for coupling peripheral devices thereto and, more particularly, to a technique which extends the distance at which the USB may operate.
2. Description of the Related Art
The Universal Serial Bus (USB) provides a method of coupling peripheral devices to a computer system. USB was developed by Intel Corporation as a general purpose port, with the intention of eliminating jumpers, IRQ settings, DMA channels, and I/O addresses. USB is a serial cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible devices. The attached devices share USB bandwidth through a token scheduled protocol. The bus allows peripherals to be attached, configured, used, and detached while the host is in operation. The USB allows many (e.g., up to 127) devices to be daisy-chained with a single standard connector. USB supports devices that transfer data from 1.5 Mbps to 12 Mbps, and is expected to support transfer rates up to 480 Mbps under the USB 2.0 Protocol Specification. By continually polling the bus for devices, users may xe2x80x9chot-plugxe2x80x9d peripherals into the system and use them without rebooting.
The USB technology may greatly simplify the complex cabling that typically spills out from the back of personal computers. USB peripherals may include keyboard, mouse, monitor, phone/answering machine, printer, scanner, fax/modem, ISDN, tablet, game controller, light pen, digital audio, and any other USB compliant device. The USB protocol assumes a short bi-directional connection between the local and remote ends of the USB network. The consequently short latencies for packet transmission allow the USB to be transaction oriented (e.g. token, data, and handshake are all completed before the next transaction begins) with very little performance loss.
The USB cable is a four wire cable, and the maximum cable length is about 5 meters. There are typically two connector types, and no cross-over cables and adapters are needed. The maximum USB cable length of about 5 meters results from the fact that the a USB Controller considers any transmission return time greater than a characteristic threshold value to be in error. USB cable lengths greater than about 5 meters may generate longer return times than the specified threshold value, and thus 5 meters is the maximum USB cable length. This 5 meter constraint may severely restrict the manner in which USB is used, especially given the fact that peripherals may be chained together sequentially. For example, in some situations it may be desirable to operate a USB and associated USB peripherals at a remote location from the associated host computer.
FIG. 1 illustrates a USB system. As FIG. 1 shows, a host computer system 108 may be coupled to various USB compliant peripherals, such as a keyboard 110A, a mouse 110B, and a monitor 110C through a Universal Serial Bus (USB) 220.
FIG. 2 is a block diagram of a host computer coupled to a variety of peripheral devices through a USB. As FIG. 2 shows, the host computer system 108 may be coupled to USB compliant peripherals, including keyboard 110A, mouse 110B, and monitor 110C through Universal Serial Bus (USB) 220. Host computer 108 may include a USB Controller 230 for coupling to USB communication medium 220. Host computer 108 may be operable to send and receive data to and from the USB peripherals shown through USB Controller 230. Host computer 108 may include USB driver software 240 which interfaces to the USB Controller 230 and facilitates communication with the USB peripheral devices. As mentioned above, there is a requirement that the total USB cable length not exceed 5 meters.
FIG. 3A is a block diagram of the software architecture of a USB system. As FIG. 3A shows, the top layer of the software architecture is application software 302. The application software 302 may be any software program which may be operable to provide an interface for control of or communication with a USB peripheral device. A USB driver program 240 may be below the application software 302. The next software layer may be OHCI driver software 306, which interfaces with the relevant hardware; i.e., the USB Controller hardware 230. The USB Controller hardware 230 communicates through USB bus 102 to various USB peripherals 110.
As FIG. 3B shows, system software 310 may include software modules that effect USB operation including client driver software 311 (which may be used by application software 302), USB driver 240, and a Universal Host Controller Driver (HCD) 306. As FIG. 3B also indicates, a hardware implementation of the system is shown in hardware 230, including Universal Host Controller (HC) 230 and USB device 110, which may be coupled by USB 102. The timing issues which result in the cable length problem exist in the host controller 230, which relies on timely acknowledgements from USB devices 110 as described in the USB specification. The host controller 312 is specified in the USB standard as having a temporal window of valid reception after each transmission between any two USB devices (controller, hubs, user devices, etc.). This period of time is 70 nanoseconds, 30 nanoseconds of which may be committed to electronic processing time in the USB Controller hardware and the other 40 nanoseconds represents the maximum time-of-flight of the data through the connecting cable. This 40 nanosecond time-of-flight issue influences the cable length limit. This timing issue is endemic to the USB process and cannot be altered. Such timing issues are described in detail below with reference to FIG. 5.
The USB is a polled bus, which means the host controller initiates all data transfers. Most bus transactions involve the transmission of up to three packets. FIG. 4 is a block diagram of a typical bus transaction. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet 402 describing the type and direction of transaction 410, the USB device address 412, and endpoint number 414. This packet may be referred to as the xe2x80x9ctoken packet.xe2x80x9d The USB device that is addressed selects itself by decoding the appropriate address fields.
In a given transaction, data may be transferred either from the host to a device or from a device to the host. The direction of data transfer may be specified in the token packet 402. As FIG. 4 shows, the source of the transaction then sends a data packet 404 containing the data to be transferred 416 or indicates it has no data to transfer. The destination, in general, responds with a handshake packet 408 indicating whether the transfer was successful 418.
Some bus transactions between host controllers and hubs involve the transmission of four packets. These types of transactions may be used to manage the data transfers between the host and full-/low- speed devices. The USB data transfer model between a source or destination on the host and an endpoint on a device may be referred to as a pipe. There are generally two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the Default Control Pipe, always exists once a device is powered, in order to provide access to the device""s configuration, status, and control information. The transaction schedule allows flow control for some stream pipes. At the hardware level, this prevents buffers from underrun or overrun situations by using an acknowledgement (ACK) handshake to throttle the data rate. When acknowledged, a transaction may be retried when bus time is available. The flow control mechanism may permit the construction of flexible schedules that accommodate concurrent servicing of a heterogeneous mix of stream pipes. Thus, multiple stream pipes may be serviced at different intervals and with packets of different sizes.
FIG. 5 illustrates the data send and acknowledgement process in a USB system as related to transmission time-outs. Referring to FIG. 5, a Data Link 504 provides a transmission medium between a Source 510 such as a USB device and a Destination 520 such as a host computer system. At time T=0 Packet 502 may be sent from the Source 510 and received at the Destination 520 at time T=A. Then, as shown in FIG. 5, at time T=B ACK 504 may be sent from the Destination 520, and received by the Source 510 at time T=C. Now, as long as C (the time of the reception of the ACK 504 from Destination 520) is less than the time-out specification of the Source 510, the Source 510 may consider the transmission transaction a success and may proceed to send the next packet of data to the Destination 520. If the timeout is exceeded the failing packet may be retransmitted by the Source 510.
Limiting the amount of time for the turnaround acknowledgment may limit the usefulness of the data exchange process in that transmission cables may be strictly limited in length to avoid time-outs. Externally increasing this timing window may result in either the ability to add the time to do processing to the data exchange chain or time to increase of the time-of-flight in the medium of the signals themselves, thus increasing the maximum cable lengths allowed by the system.
One approach to the time-out issues related to USB data transfers is to simply avoid violating the timing requirements, i.e., operate within the USB protocol specifications and accept the limitations. In this case the maximum Host-to-Functions (Device) distance is roughly six 5-meter cable lengths, or approximately 28 meters.
The second approach is to avoid one of the timing specifications, specifically the shorter of the two, which is the time-of-flight in the cable. This may be done by circumventing this aspect of the USB 1.0 process. Such an interface is illustrated by FIG. 6A. As FIG. 6A shows, a source local PC based Host Controller 108 may be connected through Link A 630 to a special interface 602 which fulfills all the PC""s USB needs for seeing less than one data bit in the cable at a single time in Link A 630. A special Hub 604 may be located at the device end of the system which provides the same service to the UBS Devices 110 attached to the system, that is, it assures that only one bit may be in the cable at that end at one time for Link C 650. It should be noted that Link A 630 and Link C 650 may be USB compliant.
In Link B 640, which is between the Interface 602 and the Hub 604, the xe2x80x9cone bit in the cable at one timexe2x80x9d rule of the USB specification is not applied. Only the overall packet response time issue is of concern. The length of the Link B 640 becomes a time/length accounting issue. As FIG. 6 shows, both the Interface 602 and Hub 604 represent process delays of 40 nS. This is also true for the end USB devices 110. Each of the standard cable lengths represents about 30 nS more delay. Given that there may only be a maximum of 415 nS in travel each way, and the cables and process each way take up roughly 160 nS (30+40+40+30+20 (half of the last turn around)), approximately 255 nS remain for signal propagation through Link B 640. In a standard cable with 65% the velocity of the speed of light as a propagation rate, the maximum distance allowable for Link B is approximately 160 feet for the single run. The addition of the two 16 foot cables at each end may then permit the cable length to be expanded from about 15 feet to about 200 feet. In this way the USB rules may be violated to permit the extension of the line.
Disadvantages of the above solution include the fact that workable solutions typically involve non-standard solutions that can further exacerbate irregularities in the communications system, there may be a reduction of robustness and accuracy in the communications system, and finally, the above solution reduces the number of allowed Hubs to one from five and thus the number of USB Function Devices that the system can accommodate.
Other techniques for addressing the time-out problem involve the placement of several USB hubs in series. Such a configuration is shown in FIG. 6B. As FIG. 6B shows, host computer 108 may be coupled through USB to a USB hub 611A. USB hubs 611B through 611E may be connected in series through USB. USB devices 110A, 110B, and 110C may be connected to USB hub 611E. Using this technique, up to five hubs may be connected in series for a total distance of 30 meters (about 99 feet). This process, in effect, simulates additional in-line hubs allowing additional cable lengths corresponding to the process times (40 ns) of each hub. This technique has, however, two basic problems:
1. By adding hubs in series to extend the distance between the computer and the final USB hub (assumed to be the xe2x80x9cwork placexe2x80x9d or xe2x80x9cdesk topxe2x80x9d), the total number of USB devices that may be connected to the system may be dramatically reduced. More specifically, as a USB hub is typically an eight port unit, and USB may typically handle up to 127 USB devices, the effective capacity of the USB may be reduced by a factor of 15 to accomplish the USB cable extension process. To retain full use of the USB system may still require a limit of 16 feet on cable lengths.
2. Even if the limitation on the number of USB devices is acceptable, the maximum distance that the USB hub may be extended is still less than 100 feet.
As used herein, the term xe2x80x9cUSB Extensionxe2x80x9d may be referred to as USBX. Systems and methods described herein may be used in various types of systems wherein a host computer communicates with one or more remote external USB devices. A host computer system may be coupled to a USB Device through a USBX Controller, Extension (USBX) bus, and USB Remote Root Hub. In one embodiment, the USBX bus cable may be longer than the maximum allowed USB cable length of 5 meters, therefore providing the capability to control peripheral USB devices beyond the typical range of USB as specified in the USB protocol specification. The USB Controller may be coupled to a keyboard, mouse, and monitor through the USB. The actual number and type of peripheral devices may be different, and may include floppy drives, tape drives, CD ROMs, scanners, or other USB compliant devices.
In one embodiment, the host computer system may be a rack-mounted system in which all workstation hardware not related to the workstation""s user interface, including hard drives, CPUs, motherboard, expansion cards, interface cards, etc., may be contained in a rack-mounted Personal Computer (PC) chassis, herein referred to collectively as xe2x80x9cthe host.xe2x80x9d The user interface hardware, such as keyboard, monitor, floppy drive, CD-Rom, or other user interface hardware, may be located remotely from the rack-mounted host and coupled to the host through the USB Extension (USBX) system. The user interface peripherals may be USB compliant devices which may be coupled to the USB Remote Root Hub via standard USB. The USB Remote Root Hub may be located in the vicinity of the user interface peripherals (subject, in some embodiments, to standard USB cabling distance limitations as described in the USB specification), and may thus be located remotely from the host. In another embodiment, a plurality of host computers may be rack-mounted in a central location with each host computer""s user interface peripheral devices, such as keyboard, mouse, and monitor, connected to the host computer through the USBX system, thereby allowing central administration and management of the host computers while providing remote access to the host computers by users through the peripherals.
The host computer may include a specialized Host Controller, also referred to as a USBX Controller, which may be coupled to the USBX bus which may in turn be coupled to the remote USB Remote Root Hub. In one embodiment, various aspects of the invention may be implemented in the USBX Controller, the USB Remote Root Hub, and the USBX bus. In one embodiment, the USBX Controller, the USB Remote Root Hub, and the USBX bus operate together to extend the USB bus to a greater distance than that specified by the USB specification.
In one embodiment, host computer may include USB driver software to facilitate communication with the USB peripheral devices. The USBX Controller may be operable to provide a USB interface, or API (Application Programming Interface) to the USB driver software, such that the USB driver software considers the USBX Controller to be a standard USB Controller. Similarly, the USBX Controller and USBX bus may be substantially transparent to the remote USB Remote Root Hub, i.e., the remote USB Remote Root Hub may operate as if local to the host computer system.
In the USBX data delivery process, according to one embodiment, a determination may be made by the USB Remote Root Hub whether there is an incoming packet from a device, such as, for example, a USB compliant keyboard. In one embodiment, the device may be a USB Hub, or function device in a USB network. If there is an incoming packet from the device, then the packet is typically saved and a copy passed to the host. In one embodiment, the host may include the USBX Controller which receives the packet. If the packet has not been received, then the USB Remote Root Hub may continue to watch for the packet.
After the incoming packet has been received, an acknowledgement may be sent by the USB Remote Root Hub to the device signaling that the packet was received. The device considers the acknowledgement to be from the host, when in fact, it originates with the USB Remote Root Hub which is local to the device. In this manner, time-out issues associated with long distances between the device and the host may be avoided. More specifically, sending the ACK may make the device operate as if the transaction were a success, thus freeing the device to process further data. Thus the device operates as if the ACK were from the host, when in fact the USB Remote Root Hub sent the ACK.
A determination may then be made whether an acknowledgement has been received from the host, indicating that the packet was received by the host. If the acknowledgement from the host has been received, then the USB Remote Root Hub typically waits for a next incoming packet. Otherwise, the USB Remote Root Hub may check for a time-out condition.
In one embodiment, if a time-out has not occurred the USB Remote Root Hub may continue to wait for the acknowledgement from the host. If there is a time-out condition, then the transaction may be considered to have failed and the USB Remote Root Hub may resend the packet to the host.
In one embodiment, the USB Remote Root Hub may check whether the packet has been resent to the host for the third time, and if not, then the USB Remote Root Hub may continue to wait for the acknowledgement from the host. If, on the other hand, the packet has been resent to the host three times, then an error routine may be called. The error routine may reset the system for fresh data, and the transaction may be considered a failure. In one embodiment, the transaction failure may be logged and/or reported to appropriate parties.
Thus, in the process described above, the data packet may be held by the USB Remote Root Hub for possible retransmission to the host until the appropriate response is received from the host. The retransmissions to the host (in response to a reception failure) may be made independently of source (device) conditions or activity. Furthermore, the process effectively circumvents the time-out characteristic of the source return to achieve the operational characteristics of a longer source time-out interval.
In the USB system the Remote Hub typically needs to know which packets are sent to and from isochronous endpoints, which typically do not use acknowledgements at all, as they are generally streaming data such as video and it would be inappropriate for the root hub to issue an ACK to these devices. To accommodate this need, the SYNC field in USBX may be modified to include information as to whether the data are isochronous or needing an ACK. Thus, the USBX system may accommodate the transfer of both isochronous and non-isochronous data.